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REMARKS 

Pending in this application are claims 48-75. 
The Examiner has rejected claims 48-75. 
Claims 1-47 were previously canceled. 

Technology Tutorial 

Applicants believe that a brief discussion of the technology disclosed in 
this application and the cited references would assist the Examiner. 
This Disclosure 

We have previously discussed our disclosure with the Examiner on 
several occasions. 
Olsen Reference 

The Olsen reference WO 98/33125 is also available in a more legible 
format as US Patent No. 6,519,642. For legibility, we are using excerpts and 
column/line citations from the US patent. 

Olsen addresses, "A system and method for creating, executing, and 
maintaining shared, automated business processes across distributed 
organizations comprises capabilities that enable interoperation among 
heterogeneous information systems." 

The Olsen reference is useful in considering the level of creative skill in 
the art. See, e.g., Ex parte Jud, App. No. 2006-1061 (BPAI decided Jan. 30, 
2007) expanded panel on reh'g. In the US application, SPE Jason Cardone 
accepted the teachings of the application as representing an inventive effort. 
This bolsters Applicants' position, because Olsen is only available as a 102(e) 
reference, not a 102(a) reference, given the declarations that have been 
accepted in this application. That is, Olsen did not become available to those of 
skill in the art for reference until after the date of our reduction to practice and, as 
of the date of Olsen's application, the allowed claims of the '642 patent 
represented inventive work, beyond the level of ordinary skill in the art. 

The Examiner focuses on FIG. 1, reproduced below: 
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From FIG. 1, we note that all three sites, the customer site 101, the manufacturer 
site 102 and the warehouse site 103, have their own copy of the Public Process 
Definition 116a. Discussion of 116a is found in cols. 5-6 and the reference 
number is used again in col. 7 line 28. 

A public process definition 116a (reference 200 in FIG. 3) is specified 
using a process definition language. Col. 5, lines 36-57. "More formally, the 
process definition language of the preferred embodiment includes node and arc 
elements that are combined with a specific ordering and logic to create a directed 
graph. ... A single source node 205-225 and a single destination node 205-225 
define each arc element. Each node 205-225 includes a set of input arcs and 
associated logic connecting it to antecedent nodes 205-225 and a set of output 
arcs and associated logic connecting it to consequent nodes 205-225. ..." In 
these passages, Olsen teaches something very specific, which Examiner 
Cardone considered inventive, which did not become available as a patent 
document to those of skill in the art until after our date of reduction to practice. 
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While the Bryan reference, discussed below, repeatedly uses the word 
"repository," that word is not used in Olsen. There is no description in Olsen of a 
repository shared among different sites 101, 102, 103, either by that name or any 
synonym. What Olsen teaches is a protocol for an authoring service to push an 
update installation message to all participant sites. Col. 11, lines 17-35. 

Olsen teaches that "the public process definition 116a/200 is distributed to 
the different sites 101, 102, 103 by a manager set 482, which initiates the 
installation of the process definitions into engine 484. During installation, the 
execution engine 484 transforms the process definitions it receives into 
executable state machines which are saved in database 410." Col. 9, lines 10-15. 
Olsen does not teach a service providing, in response to a request, one or more 
machine-readable specifications from a registry via a communication network to 
a requesting node. Instead, Olsen pushes software updates to participants. 
Bryan Reference 

The Examiner also has cited "Guidelines for using XML for Electronic Data 
Interchange"; Version 0.02; Editor: Martin Bryan, The SGML Centre; September 
12, 1997 ("Bryan"). We suggest that the Examiner visit 

www.geocities.com/WallStreet/Floor/5815/guide.htm720079 to view Version 0.05 
of Bryan, which has pictures added and some text, at a date that does not qualify 
it as a 102(b) reference. The pictures help understand the reference. 

The Bryan reference builds up to previewing XSL with a code example 
that substitutes an XML message to be delivered to a browser for a more 
traditional EDI message. The XML message code is accompanied by a DTD 
definition statement and a sample, proto-stylesheet for rendering XML to a 
browser. In the introduction to the example, Bryan explains that the reference is 
intended to preview using XML Stylesheet Language ("XSL") to format an XML 
message, as "Unfortunately the XSL specification has not yet been made public 
. . . When it is published a pointer . . . will be placed here. fll,] For an example of the 
use of XSL specifications refer to Appendix A." Id., p. 19. The example XML, 
DTD and proto-stylesheet appear at pp. 19-28. The first half of Bryan is a akin to 
a literature review or background section. The second half teaches about XSL. 
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A timeline of XML-related development helps us understand where Bryan 
was compared to the ordinary skill in the art. Author Kenneth Sail, on his XML 
Family of Specifications Timeline, gives "8/98 - 10/1" as the era of Extensible 
Stylesheet Language (XSL) Version 1 .0, which is after the date of reduction to 
practice for these claims. Kenneth B. Sail, XML Family of Specifications, A 
Practical Guide (May, 2002) (timeline published with book). The Examiner should 
recognize XSL as a predecessor to XSL Transformation language ("XSLT") 
Version 1 .0, which Sail dates as "4/99-1 1/99", after this application was filed. A 
copy of Sail's book and timeline are available to the Examiner by contacting 
Primary Examiner William Bashore. The timeline suggests that Bryan was at the 
cutting edge of skill in the art and that development beyond Bryan was at the 
inventive frontier of XML tool development. 

The Definitions section of Bryan, at pp. 3-4, explains EFIFACT, a 
predecessor to XML. References to a field description table for each EDI 
message and to a data element dictionary describe technology akin to a 
database definition, with optional and mandatory elements. 

On page 5, reference is made to a pointer in the context of an invoice. 
During processing of an invoice, the line items of the invoice were stored in a 
database. The pointer identified the database from which the invoice data would 
be fetched each time the invoice was processed. 

The XML/EDI Components section, at pp. 8-12, portrays XML parsers, 
document browsers, page mark-up programs and related software functions as 
available, off the shelf, in 1 997. Remember that stylesheets were not part of the 
available software, because the XSL standard draft had not been released to the 
public when Bryan wrote the reference. 

For development, at p. 9, Bryan suggests that new applications be 
created. He lists components that did not yet exist, saying "specific components 
will ... manifest themselves ... new applications will be created from the spark ... 
The following list [is] ... a starting place for development.") 

The Examiner has noticed, in the starting list for development, Bryan's use 
of the phrases "Lexicon Repositories" and "XML/EDI Business Objects (Java 
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applets and Active X components)", pp. 9-12, but has not discussed what Bryan 
teaches about these items for development, reading Bryan as a whole. We 
emphasize that these phrases are in Bryan's list of things to be developed. 

Bryan envisions development of Lexicon Repositories, including DTD 
Repositories. But he does not teach anything about what would be found in the 
repositories, except what the two-word name suggests. A "DTD Repository" 
might contain DTDs, but Bryan does not suggest what elements would be in a 
particular DTD found in the repository or any extensions to the DTDs of 
September 1997. Unless one already knew what a DTD repository would be, 
Bryan is not enabling. The two words "DTD Repository" in a list of things to be 
developed, does not read on the more detailed words of our claims. Instead, it 
suggests a strongly felt need for something like what Melter et al. / Veo / 
Commerce One developed. 

Developing DTDs, at pp. 13-15 identifies groups that should work on 
developing DTDs and gives some simple code examples. Bryan predicts, "XML 
DTDs will typically be stored in separate files, which can be referenced, as an 
XML external subset, by those wishing to use it through the Internet Uniform 
Resource Locate that its originator has assigned to a publicly available copy of 
the data." This prediction teaches more about exposing DTDs for reference, but it 
still does not go beyond the older practice of using include statements in program 
code to reuse data structure definitions stored somewhere else. 

The Creating Message Instances section, at 15-16, again uses the word 
"pointer," this time to refer to the first line of an XML message as including a URL 
at which a DTD might be found. We point out that neither the syntax or semantic 
that Bryan used in September 1997 for the "pointer" prevailed in XML Version 
1 .0. Moreover, Bryan's code examples are not clean and well-formed - they 
require various edits to properly validate against the XML version 1 .0 language 
definition, which indicates that XML editors were relatively primitive in September 
1997 or the language definition was still in flux. 

XSL is previewed at pp. 17-19. 
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After background on book ordering in England, Bryan give an XML 
encoded Book Order Message at pp. 21-22. This XML message could be used 
to communicate an order for a pair of books entitled "Chrome" and "William 
Morris", in lieu of an EDI message specified by the European Board of EDI 
Standardization, in the EDItEUR EDI Implementation Guidelines for Book Trade 
Distribution. The message definition for this one message spans pp. 22-25 of the 
appendix. A proto-stylesheet, identified as "Processing Rules" appears as Figure 
A.4 at pp. 26-28. 

Bryan previews how to send an XML message to a browser for display 
using a stylesheet. On the way to previewing XSL as a stylesheet language, 
Bryan names a variety of tools that need to be developed, but it is clear that the 
tool about which he is teaching is XSL, not repositories. 

With this discussion of the references in mind, we turn to the Examiner's 
rejections. 

Rejection Under 35 U.S.C. S 102(b) of Claims 48-75 

The Examiner rejects claims 48-75 under 35 U.S.C. § 102(b) as 
anticipated by "Guidelines for using XML for Electronic Data Interchange"; 
Version 0.02; Editor: Martin Bryan, The SGML Centre; September 12, 1997. 

As explained above, these guidelines preview use of the not-yet public, 
soon to be published XSL standard for stylesheets. 
Claim 48 

Claim 48 includes the limitations: 

maintaining a registry of machine-readable specifications specifying 
business services offered by trading partners, the machine- 
readable specifications including at least one of definitions of, and 
references to definitions of, services offered and at least one of 
definitions of, and references to definitions of, documents to be 
exchanged with such services by trading partners; and 

providing, in response to a request, one or more of the machine- 
readable specifications from said registry via a communication 
network to a requesting node. 

These limitations are not found in Bryan. 

Pages 8-10 of Bryan, particularly where they refer to any repositories, 
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describe things remaining to be invented, anticipated only in the sense that the 

writer hopes that someone will fulfill recognized needs. Bryan makes it clear that 

the claimed subject matter had not been invented when the Guidelines were 

published in September, 1997. He wrote: 

The following XML/EDI specific components will either manifest 
themselves as built-in components into existing products, plug-in 
progams to existing tools, ActiveX controls, or standalone 
applications. It is anticipated that new applications will be 
created from the spark of XN I LI EDI implementation. The following 
list isn't comprehensive, but a starting place for development. 

(boldfacing added.) To the extent that the Examiner relies on mention of 

repositories on pp. 8-10, the reliance is misplaced and there is no basis for a 

section 102 rejection. 

The Examiner also relies on definitions on pp. 3-4. The only plausibly 

relevant passages that we see on pp. 3-4 are: 

EDIFACT messages are transmitted in compressed form, using 
predefined field identifiers, which must occur in a predefined 
sequence. While EDI is, strictly speaking, wider in scope than 
EDIFACT, for the purposes of these guidelines EDI will be used in 
this restricted sense when not otherwise qualified. 



Originally, EDI translation software was developed to support a 
variety of private system formats. Most often, the sender and 
receiver were required to contract in advance for a tailored software 
program that would be dedicated to mapping between their two 
types of datasets. Each time a new sender or receiver was 
added to the client list, a new translation program would be 
needed by the new party to format their data to conform to the 
standards in use by the participants. Of course, this becomes 
expensive. 

This passage describes EDIFACT as a marginal improvement over legacy EDI 
translation software in a different direction than these inventors pursued; it does 
not describe any aspects of EDIFACT that read on claim 48. While Bryan 
previews the not yet released XSL standard with a code sample and lists a 
number of additional development projects to be undertaken, Bryan does not 
enable or provide a written description of what we claim. 
Therefore, claim 48 should be allowable over Bryan. 
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Claims 49-51 

Claims 49-51 should be allowable over Bryan for at least the same 
reasons as the claim from which they depend. 
Claim 52 

Claim 52 includes the limitations: 

wherein the machine-readable specifications include documents 
compliant with a definition of a predefined document including 
logical structures for storing an identifier of a particular transaction, 
and at least one of definitions and references to definitions of input 
and output documents for the particular transaction 

These limitations are not found in Bryan. The discussion on which the Examiner 

relies, at pp. 13-14, describes the use of Data Type Definitions (DTD) with XML 

messages, either by reference or incorporated in the messages. This use of 

DTDs does not read on machine readable specifications for (a) a transaction 

identifier, (b) an input document and (c) an output document for the identified 

transaction. There is nothing inherent in the use of DTD that teaches what we 

claim. 

Therefore, claim 52 should be allowable over Bryan. 
Claim 53 

Claim 53 includes the limitations: 

wherein the storage units comprise parsed data 
These limitations are not found in Bryan. Use of XML data teaches use of 
parsable, not parsed data. 

Therefore, claim 53 should be allowable over Bryan. 
Claim 57 

Claim 57 should be allowable over Bryan for at least the same reasons as 
the claim from which it depends. 
Claim 58 

Claim 58 includes the limitations: 

including associating trading partners with said machine readable 
specifications 

These limitations are not found in Bryan, machine readable specifications or any 
association between the specifications and trading partners. 
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Therefore, claim 58 should be allowable over Bryan. 
Claims 54-56 and 59-75 

Claims 54-56 and 59-75 include many more limitations than the character 
data encoding and markup data identifying limitations to which Examiner refers to 
on page 4 of the office action. For instance, claim 59 is a device claim that 
includes: 

a data processor coupled to the memory and the network interface 
which executes programs of instructions; wherein the programs of 
instructions include 

logic to provide, in response to a request received at the network 
interface, one or more of the machine-readable specifications from 
said registry via a communication network to a requesting node 

Similar limitations are found in independent claim 65. These limitations are not 

found in Bryan and Bryan does not read on these limitations. 

Therefore, claims 54-56 and 59-75 should be allowable over Bryan. 

Applicants respectfully submit that claims 48-75 should be allowable over 

Bryan. 

Rejection Under 35 U.S.C. § 102(e) of Claims 48-75 

The Examiner rejects claims 48-75 under 35 U.S.C. § 102(e) as 
anticipated by Olsen et al. (WO 98/33125) (Designates the US; printed in 
English). 
Claim 48 

Claim 48 includes the limitations set forth above. These limitations are not 
found in Olsen. Olsen describes "A system and method for creating, executing, 
and maintaining shared, automated business processes across distributed 
organizations" but not the claimed system and method. In Olsen, neither the 
word "repository" or any of its synonyms is used. Olsen teaches an authoring 
site 101 pushing updated public process definitions 116a/200 to participant sites 
102, 103. Col. 11, lines 17-35. Olsen does not teach a service providing, in 
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response to a request, one or more machine-readable specifications from a 
registry via a communication network to a requesting node. 

Therefore, Olsen does not read on claim 48 and the claim should be 
allowable over Olsen. 
Claims 49-51 

Claims 49-51 should be allowable over Olsen for at least the same 
reasons as the claim from which the depend. 
Claim 52 

Claim 52 includes the limitations: 

wherein the machine-readable specifications include documents 
compliant with a definition of a predefined document including 
logical structures for storing an identifier of a particular transaction, 
and at least one of definitions and references to definitions of input 
and output documents for the particular transaction 

These limitations are not found in Olsen. Olsen is an extension of an authoring 

system, not a registry of specifications or a service that responds to requests. It 

does not deliver specifications that include a transaction identifier and definitions 

of both input and output documents. 

Therefore, claim 52 should be allowable over Olsen. 
Claim 53 

Claim 53 includes the limitations: 

wherein the storage units comprise parsed data 

These limitations are not found in Olsen. Olsen's XML data structures are 
parsable, rather than parsed data. 

Therefore, claim 53 should be allowable over Olsen. 
Claims 57-58 

Claims 57 and 58 should be allowable over Olsen for at least the same 
reasons as the claim from which they depend. 
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Claims 54-56 and 59-75 

Claims 54-56 and 59-75 include many more limitations than the character 
data encoding and markup data identifying limitations to which Examiner refers to 
on page 4 of the office action. For instance, claim 59 is a device claim that 
includes: 

a data processor coupled to the memory and the network interface 
which executes programs of instructions; wherein the programs of 
instructions include 

logic to provide, in response to a request received at the network 
interface, one or more of the machine-readable specifications from 
said registry via a communication network to a requesting node 

Similar limitations are found in independent claim 65. These limitations are not 

found in Olsen, which describes an authoring and push technology. Olsen does 

not read on these limitations. 

Therefore, claims 54-56 and 59-75 should be allowable over Olsen. 

Applicants respectfully submit that claims 48-75 should be allowable over 

Olsen. 



Page 19 of 20 



Application No.: 09/633,365 



Atty. Docket: OIN 1006-2 



CONCLUSION 

Applicants respectfully submit that the pending claims are now in condition 
for allowance and thereby solicit acceptance of the claims as now stated. 

Applicants would welcome an interview, if the Examiner is so inclined. 
The undersigned can ordinarily be reached at his office at (650) 712-0340 from 
8:30 a.m. to 5:30 p.m. PST, Monday through Friday, and can be reached at his 
cell phone at (415) 902-61 1 2 most other times. 

Fee Authorization. The Commissioner is hereby authorized to charge 
any additional fee determined to be due in connection with this communication, 
or credit any overpayment, to our Deposit Account No. 50-0869 (OIN 1006-2). 

Respectfully submitted, 

Dated: July 9, 2007 /Ernest J. Beffel. Jr./ 

Ernest J. Beffel, Jr. 
Registration No. 43,489 

Haynes Beffel & Wolfeld LLP 
P.O. Box 366 

Half Moon Bay, CA 94019 
Telephone: (650)712-0340 
Facsimile: (650)712-0263 
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